Stuck on a significant data discrepancy in our analytics reporting for Virtual Agent interactions that involve handoffs to human agents via our BYOC trunks. We are operating in the Singapore region, managing 15 distinct BYOC trunks across different carriers, and the reporting engine seems to be losing the thread of the conversation context during the SIP re-INVITE phase.
The specific issue manifests when a Virtual Agent, configured via the latest Architect flow updates, determines a human is required and triggers a handoff to a queue. The initial SIP INVITE is established correctly, and the Virtual Agent session logs show a successful transfer. However, once the call bridges to the agent, the analytics dashboard reports the Virtual Agent interaction as ‘Ended’ or ‘Disconnected’ rather than ‘Transferred to Queue’. This results in a skewed view of our bot containment rates and agent assist metrics.
We have verified the SIP traces on our carrier side. The traces show a clean 200 OK response for the re-INVITE, and the SDP negotiation completes without error. The Genesys Cloud side logs indicate the media path is established. Yet, the interaction object in the API (/api/v2/interactions/{id}) does not reflect the continuation of the session ID. It appears as a new, orphaned interaction linked to the agent leg, while the bot leg is closed prematurely.
This is particularly problematic because we rely on these metrics for capacity planning and AI model training feedback loops. If the handoff is not recorded as a successful transfer, the feedback loop breaks, and we cannot accurately measure the bot’s effectiveness in routing complex queries. We have attempted to adjust the ‘Transfer Mode’ in the Architect settings from ‘Blind’ to ‘Attended’, but the divergence persists. The error code logged in the system events is a generic ‘Session Context Lost’ warning, which provides little actionable insight.
Has anyone encountered similar issues with BYOC trunks and Virtual Agent handoffs? We are using the standard SIP trunk configuration with no custom codecs or complex DTMF settings. The issue appears consistently across multiple carriers, suggesting it might be a platform-side parsing issue rather than a carrier-specific quirk. Any insights on how to force the analytics engine to maintain the session context across the handoff boundary would be greatly appreciated.