SIP Trunk Analytics Export Stalling During Screen Recording Session Initiation

Just noticed that our automated screen recording sessions are timing out specifically when the background process attempts to fetch real-time BYOC trunk health metrics.

We are running a custom Architect flow that triggers a screen recording via the Engagement API whenever a high-priority queue call is answered. This flow includes a Data Action to pull the current registration status and jitter metrics for our 15 active BYOC trunks to append to the recording metadata for compliance auditing. The issue arises during peak APAC hours (09:00-17:00 SGT). The screen recording service initiates correctly, but the Data Action hangs for approximately 45 seconds before returning a generic 504 Gateway Timeout. This delay causes the screen recording session to fail initialization because the platform expects the metadata payload within a 5-second window. We have verified that the SIP credentials are valid and the trunks are registered. The Analytics API endpoint /api/v2/analytics/details is being hit, but the response time spikes only when the screen recording service is the caller. If we run the same Data Action in a separate test flow without the screen recording trigger, it completes in under 2 seconds. Is there a known conflict between the screen recording service’s thread pool and the Analytics API rate limiter? We need to ensure the recording captures the agent interaction without dropping the call due to metadata retrieval failures. Current SDK version is 1.0.42. Any insights on optimizing this data fetch or bypassing the timeout would be appreciated.

The simplest way to resolve this is to decouple the trunk health check from the recording trigger. Run the BYOC metrics fetch on a separate thread or schedule it asynchronously.

Direct API calls during high-concurrency screen recording initiation can hit WebSocket connection limits. This blocks the Engagement API response. Check your API throughput logs for 429 errors.