No idea why this is happening, the SIP registration drops to 408 on secondary trunks when querying high-volume analytics:
check your oauth token refresh logic specifically for the apac edge. the 408 isn’t a sip issue, it’s a platform api bottleneck. when you hit /api/v2/analytics/details/interactions with that date range, the backend takes longer than the default keepalive window. the secondary trunks drop because the thread holding the session is blocked waiting for the analytics response. you need to decouple the analytics query from the sip registration thread. implement a background worker for the api call. also, ensure your multi-org validation isn’t timing out during the refresh. the eu1 and apac regions have stricter concurrency limits on token validation. if the token refresh hangs, the whole connection drops. try reducing the interval to 1 hour chunks and batch the requests. this usually resolves the timeout on failover routes.
What’s happening here is that blocking the SIP keepalive thread with heavy analytics queries causes the 408 timeout. Decouple the logic using a background worker or webhook trigger. See the async execution patterns here: https://developer.genesys.cloud/api/v2/async. Keep your ServiceNow integration separate from real-time telephony threads to prevent session drops.