Stuck on a problem and need help troubleshooting a critical visibility gap in our Performance dashboard regarding SIP trunk utilization. Our organization relies heavily on the Performance app to monitor real-time queue activity and agent adherence, yet we are seeing a significant divergence between the actual telephony load and the metrics presented in the dashboard during peak hours.
The environment is running Genesys Cloud CX (Release 24.2). We have configured a dedicated SIP trunk connection for high-volume inbound campaigns. When the concurrent call count approaches the trunk’s configured limit of 500 channels, the Performance dashboard continues to display available capacity within the associated routing strategy. This leads to a false sense of security for our workforce management team, who believe they can handle more volume than the telephony infrastructure actually supports.
To clarify the behavior, please refer to the following reproduction steps:
- Initiate a synthetic load test against the specific SIP trunk endpoint using a tool like Sipstone, driving concurrency to 95% of the trunk’s maximum capacity.
- Simultaneously, open the Performance dashboard and navigate to the ‘Queue Activity’ view for the routing strategy linked to this trunk.
- Observe the ‘Calls Waiting’ and ‘Available Agents’ metrics. Note that the dashboard does not trigger any saturation alerts or reflect the blocked calls occurring at the trunk level.
- Compare these dashboard figures with the raw call detail records (CDRs) exported from the Telephony Management section, which clearly show the ‘486 Busy Here’ or ‘503 Service Unavailable’ responses generated by the trunk provider.
The discrepancy suggests that the Performance app is not ingesting the real-time SIP status updates or that there is a latency issue in how trunk-level constraints are communicated to the queue metrics. We require these metrics to be synchronized to ensure our operational decisions are based on accurate data. Is there a specific configuration setting for SIP trunk monitoring that needs to be enabled, or is this a known limitation in how Performance aggregates telephony health data? Any guidance on aligning these views would be appreciated.