Is it possible to establish a direct correlation between the latency metrics observed on our 15 BYOC trunks in the Asia/Singapore region and the response times recorded in the Digital Messaging API endpoints? We are currently troubleshooting intermittent delays in WhatsApp message delivery that seem to coincide with high-volume failover events on our secondary trunks. The issue manifests as a 408 Request Timeout error when calling the /api/v2/communications/digital-messaging/conversations endpoint, specifically during peak hours when the SIP registration stability dips slightly. We have verified that the carrier-specific quirks for our primary providers are accounted for in the outbound routing rules, yet the digital channel appears to suffer from similar congestion patterns. The environment details include Genesys Cloud release 2023-12, Architect v2.1, and custom Data Action scripts that parse SIP headers for analytics. When the trunk failover logic triggers, we observe a spike in sip.register.status anomalies, which correlates temporally with the API timeouts. We need to determine if the underlying SIP transport layer is impacting the WebSocket connections used by the digital messaging stack or if this is an isolated application-layer issue. The null pointer exceptions previously encountered in the Data Action scripts have been resolved, but the latency issue persists. We are looking for insights into how the BYOC trunk health metrics can be integrated into the digital messaging analytics reporting to provide a unified view of channel performance. Specifically, we want to know if there is a documented dependency between the SBC TLS certificate validation status and the digital messaging API gateway’s connection pool management. Any guidance on configuring alerts that trigger based on combined SIP and API latency thresholds would be greatly appreciated, as our current monitoring setup treats these systems in isolation.