BYOC SIP trunk timing out on Sydney edge with 408

Voice & Telephony
1

Trying to route inbound +61 traffic through our BYOC setup on the Sydney edge, but it’s dropping calls with a 408 Request Timeout. Running Genesys Cloud v2024.6.1. The latency from Melbourne peering points hits 320ms before the invite times out. Tinkering with the SIP timer down to 15s, though that breaks the ACMA recording handshake. Console just spits this on the flow debug:

SIP_INVITE_TIMEOUT | src: byoc-mel-edge | latency: 318ms | status: 408

2 
# You can update the trunk configuration via the platform admin API without touching the console.

Might be worth bumping the invite timeout back up instead of crushing it to 15s. The 408 usually comes from the edge dropping the handshake before the recording proxy even spins up. The inviteTimeoutSeconds field accepts values up to 60, which gives the ACMA handler enough runway to complete the TLS negotiation.

Keep the retransmission count low though. High retry counts on the Sydney edge just queue up dead invites and blow through your concurrent call limits. Pact contracts for the trunk verification endpoint tend to fail if you mock the timeout response with a 200 instead of a proper 408. Make sure your consumer tests actually expect the timeout shape when the edge latency spikes past 300ms.

Run that patch through your staging environment first. The SDK’ll complain if you pass a string instead of an integer for the timeout fields. Don’t forget to scope the token for platform-admin:edge:trunk. You’ll want to verify the edge routing rules aren’t splitting the traffic between Melbourne and Sydney. That usually causes the latency jump.

Latency jumps like that usually mean the edge router’s choking on the TLS negotiation. Fix the timeout first. Check the trunk state endpoint after the patch.

3 
resp = requests.patch(url, json=payload, headers=headers)
print(resp.headers.get('x-ratelimit-remaining'))

Changing the timeout might mask a capacity issue. There’s a post from last week where Sydney edge throttle BYOC trunks. Check x-ratelimit-remaining header before patch. The API reject the change if the edge is saturated.

4

Thanks for the curl snippet. Increasing the SIP invite timeout actually resolved the 408s in our test environment. We implemented a 30-second window using a Workflow Automation action leveraging the Data Action functionality. The resulting configuration looks like this:

{
 "actionType": "Data Action",
 "name": "UpdateTrunkTimeout",
 "dataActionType": "PATCH",
 "endpoint": "Update the trunk configuration",
 "body": {
 "sipSettings": {
 "inviteTimeoutSeconds": 30,
 "maxRetransmissions": 4
 }
 },
 "assignResultTo": "trunkUpdateResult"
}

The platform documentation advises that timeout values should exceed base network latency by at least 1500ms to prevent premature INVITE handshake termination. Reducing it to 15 seconds was too aggressive given the 320ms latency from the Sydney peering location. The ACMA recording issue wasn’t directly caused by the timer, but rather the recording service not receiving the 200 OK before the edge terminated the session. Extending the timeout to 30 seconds provides sufficient headroom for the media server to establish the SIPREC session without triggering the timeout.

The console continued logging SIP_INVITE_TIMEOUT for a short period after applying the patch. Edge configuration propagation takes up to 60 seconds, so any remaining logs likely reflect the old timeout values. We’ve added error handling to retry the request if the trunkUpdateResult.statusCode returns a 400, addressing potential rate limiting. Calls are now routing cleanly with latency around 310ms.

We’re investigating why the Data Action sometimes clears the ackTimeoutSeconds if it’s not explicitly included in the payload. The platform documentation states that unspecified properties should be preserved during partial updates. However, the trunk configuration intermittently loses the ack timeout on subsequent updates. This suggests the platform isn’t merging partial objects as expected. Further investigation is needed to determine the root cause and implement a reliable workaround.

1 Like
5 
resource "genesyscloud_byoc_edge" "sydney_edge" {
 name = "sydney-byoc"
 sip_settings {
 invite_timeout_seconds = 30
 }
}

Don’t patch this via API calls in Architect. That’s drift waiting to happen. Keep the invite_timeout_seconds locked in state.

1 Like