Can anyone clarify the expected behavior of the Telephony dashboard when a SIP trunk configuration forces a specific codec negotiation that differs from the Genesys Cloud default? We are observing a significant spike in abandonment rates within the EU-West environment, specifically affecting the high-priority sales queue. The issue appears correlated with recent updates to our primary SIP trunk provider, which has enforced G.711u-law as the mandatory codec for all inbound traffic.
In the Queue Performance view, the ‘Abandoned’ metric is increasing, yet the ‘Average Speed of Answer’ remains stable. This discrepancy suggests that calls are not failing to connect but are being terminated prematurely or rejected during the initial handshake. The Architect flow for this queue is standard, utilizing a simple ‘Set Queue’ action followed by a ‘Wait’ node. There are no conditional branches or complex logic that would cause immediate hang-ups.
When reviewing the Conversation Detail view for the affected interactions, the status often shows as ‘Not Answered’ with a duration of less than two seconds. The error log provided by our telecom vendor indicates a codec mismatch, but Genesys Cloud should handle transcoding automatically.
SIP/2.0 488 Not Acceptable Here
Contact: <sip:[email protected]>
Content-Type: application/sdp
The concern is whether the Genesys Cloud performance metrics are accurately capturing these technical failures as ‘abandonments’ rather than ‘system errors’ or ‘failed connections.’ If the dashboard is misclassifying these events, our business stakeholders are receiving incorrect data regarding agent workload and queue efficiency. We need to understand if there is a specific configuration in the Telephony settings or the Architect flow that must be adjusted to ensure the codec negotiation is handled correctly before the call enters the queue. Additionally, is there a way to filter the Conversation Detail view to isolate calls that failed due to SIP trunk errors versus actual customer hang-ups?