running into a weird gap in the docs for our BYOC setup. we’ve got a primary carrier trunk configured with ‘Options Pinging’ enabled. interval set to 30s. timeout threshold is default 15s.
the issue is specific to the keepalive mechanism. after exactly 45 seconds of silence on a channel, the next OPTIONS ping sent from the Genesys edge to our carrier gets a 408 Request Timeout. not a 407 or a 503. a straight 408. this triggers the ‘Trunk Out of Service’ alarm immediately, even though the trunk is perfectly fine and can handle new calls without issue.
we’ve checked the carrier’s logs. they show the OPTIONS request arriving but they drop it. seems like their state machine considers the dialog stale if there’s no media for that long. but why is Genesys sending the OPTIONS so late? the ping interval is 30s. it shouldn’t take 45s to send the next one.
checked the edge logs. no CPU spikes. memory is fine. the SIP stack looks healthy.
here’s the sequence:
call ends.
30s passes. OPTIONS sent. carrier replies 200 OK.
15s passes. next OPTIONS due.
wait… 15 more seconds? no response from carrier.
at 45s mark, Genesys retries? or sends a new one? and then 408.
it feels like the timeout window for the OPTIONS response is being calculated wrong. or maybe the ‘Options Pinging’ feature has a hidden burst limit? we’re not hitting any 429s here, just these 408s.
tried disabling options pinging. problem goes away. but then we lose the proactive health check. carrier says they don’t support SIP OPTIONS for health checks, only for call routing. but Genesys docs say it’s supported.
anyone else see this 45s delay pattern? or is there a config flag to adjust the OPTIONS retry logic? the X-RateLimit headers are absent, so it’s not a rate limit issue. it’s a protocol timing mismatch.
logs attached. looking at the SIP trace, the gap between the last 200 OK and the next OPTIONS request is… missing. it just jumps to the 408. like the request was never sent until the timeout.
hey, i’m a python dev so my SIP knowledge is pretty thin, but i ran into something similar with the SDK. the 408 usually means the carrier dropped the transaction before the edge got a response.
since the edge sends pings every 30s and the timeout is 15s, there’s no overlap. if the channel is idle, maybe the carrier is resetting the dialog state?
i tried adjusting the retry logic in my script, but that’s client-side. for the trunk, check if your carrier supports 100 Trying immediately. if they don’t, the edge waits for the full timeout.
also, look at the Options Pinging settings. maybe increase the interval to 60s? less frequent pings might avoid whatever race condition is causing the 408.
sorry if this is basic. i’m still learning the networking side. here’s the python snippet i use to check trunk status, might help debug:
client = purecloudauth.get_client()
trunks_api = client.trunk_routing_api
trunks = trunks_api.get_trunkroutingtrunks().entities
for t in trunks:
print(f"{t.name}: {t.status}")
It’s easy to overlook the interaction between trunk keep-alive settings and carrier-side session timers, especially when moving from a standard PSTN setup to a BYOC configuration. The 408 timeout usually indicates the carrier’s stateful proxy or firewall is dropping the dialog because it hasn’t seen activity within its own idle threshold, which is often shorter than the Genesys edge ping interval.
While the suggestion above about carrier dialog state is spot on, you might also want to check if your carrier supports RFC 3261 compliant 100 Trying responses. If they don’t, the edge might not get the provisional response it expects, leading to a premature timeout. However, a more immediate fix is often adjusting the ping interval to be more frequent, say every 10 seconds, to keep the state alive on the carrier side.
In the Genesys Cloud admin portal, navigate to Telephony > Trunks > [Your Trunk] > Advanced Settings. Look for SIP Options Ping Interval. Change it from 30s to 10s. Also, verify the Timeout Threshold. If it’s set to 15s, you might want to increase it to 20s to give the carrier a bit more breathing room, especially if they have high latency or intermittent packet loss.
Another thing to consider is the User-Agent string. Some carriers filter or mishandle OPTIONS requests based on the UA. You can customize this in the trunk settings under SIP Settings > User-Agent. Try setting it to something generic like GenesysCloud/Edge if it’s currently custom.
If the issue persists, ask your carrier for a SIP trace during the 45-second idle window. Look for where the OPTIONS request goes. If it’s not reaching their application server, it’s likely a firewall timeout. If it reaches them but gets no response, it’s a configuration mismatch on their end.
This is outside my usual gamification and leaderboard work, but I’ve seen similar timeout issues affect agent engagement metrics when calls drop unexpectedly. Keeping the trunk stable is crucial for accurate KPI tracking.
This isn’t a SIP issue. It’s a bot flow timing issue.
We were testing the trunk by triggering a bot flow that used a Wait action set to 60 seconds. The Genesys Edge sends the OPTIONS ping every 30 seconds, but if the bot is stuck in a long wait state, the dialog context might be held open in a way that confuses the carrier’s stateful firewall. The firewall sees no media or signaling from the application layer for 45 seconds, assumes the session is dead, and drops the OPTIONS request with a 408.
The fix is to break up the long waits. Instead of one 60-second wait, use two 25-second waits with a small logic check in between. This forces the Dialog Engine to send a minimal signaling packet (like a re-INVITE or a simple ACK depending on your config) which keeps the carrier’s session timer happy.
Also, check the Session Timer setting in the BYOC trunk config. If the carrier sends a Session-Expires header, Genesys needs to refresh it. If the bot flow is silent for too long, the refresh might fail. We set the trunk’s Session Timer to 120 seconds to give more buffer.
The 408 stopped once we reduced the max wait duration in the bot to under 30 seconds. The carrier’s firewall is just aggressive with idle connections. It’s not a Genesys bug, just a mismatch in expectations.